Software products are sold by vendors to various customers across multiple geographies. A software product is a complex amalgamation of components which may or may not have subcomponents. For the software product to function correctly, the components and subcomponents, which are dependent on one another, ought to function correctly. For example, a component may be dependent on hierarchically related subcomponents. However, due to the complexity of software products, the components and/or subcomponents invariably have defects, which may cause other components not to function properly.
Customers using the software product may experience errors (e.g., bugs, program faults, coding errors) caused by the defects. The source of a defect is typically a specific component or subcomponent of the software product. Likewise, a defect typically affects a specific component or subcomponent. The likelihood that the component or subcomponent will require a remedy, such as a software patch, increases with the number of defects that the component or subcomponent has.
Customers' feedback informs a vendor of the errors that the customer has experienced while using the vendor's software product. The vendor combines the customers' feedback using traditional measurements (e.g., bar graphs, stacked graph, defect trend lines) in order to assess the kinds of problems that customers are experiencing with the software product. However, traditional measurements do not visually represent that components and/or subcomponents are arranged in a hierarchical fashion. For example, a bar graph may show the number of defects that components and subcomponents have, but not how components and subcomponents are interrelated. Likewise, traditional measurements do little to predict components that will require remedy or expose the size of problems in components relative to the software product as a whole. Accordingly, traditional measurements do not convey the full effect of a defect on the software product.